Software lifecycles begin in the development environment in which developers strive to create and perfect the program. As development proceeds various versions of the application evolve on the development server(s) used to code, test, and debug the application. Frequently, each version of the application requires different resources from the server in order to run properly. Likewise, because the environment of each server can differ from the others, the installation of an application on a particular server often requires resources from that server that may be unique to that server. Once the application is operational, each installation in a large scale deployment can be virtually unique thereby creating a nightmare for the support team called upon to deploy the application. These difficulties occur across a wide range of technologies other than application servers including, but not limited to, mobile telecommunication networks, database servers, computing networks (LANs or WANs), web servers, and enterprise service buses.
For instance, Java Platform Enterprise Edition (referred to as J2EE) is a platform for developing and executing distributed, multi-tiered, Java applications. In this case, deployment is the act of installing components for a J2EE application and configuring a J2EE Application Server to run the J2EE application. Deployment of these applications can occur multiple times to multiple targets during the development life cycle and can occur to application servers provided by a multiplicity of vendors. Because each application server may be configured differently, configuring application servers during deployment can be a time consuming and inefficient task.
Current deployment methods include manual deployment, using vendor specific GUI applications (i.e., installation “wizards”), using vendor specific command line tools (e.g., scripting etc.) and creating custom installation utilities. These current methods, however, suffer several shortcomings. Manual deployment is time consuming and error prone during both initial installation at a target and during updating. Furthermore, documentation related to the changes needed for the application server must be manually updated after changes to the application or the application server. Manual installation also provides limited, if any, versioning. Using vendor specific GUI applications also leads to time consuming and error prone installations and updates. Furthermore, installation applications are typically tied to the particular vendor's system, necessitating the purchase of multiple installation applications if the code is to be installed on multiple vendors' servers. Training is also typically required for each vendor's system. Likewise, vendor specific command line tools require developer intervention for changes and are also often tied to a single vendor's system. Thus, changes are difficult to synchronize across multiple vendors' systems. Moreover, vendor specific command line tools are time consuming for the developer, lack versioning, require training and also require manual updates. Similarly, existing custom utilities are generally expensive, time consuming and are not adequately robust to handle a variety of installations on multiple vendors' systems.